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DETAILED ACTION 

1 . This communication is in response to Applicant's Amendment filed 5/04/09, 
claims 1-8, 19-25 and 27-30, have been amended, claims 1-9, 11-25, and 27-30 remain 
pending. 

2. The granted decision mailed on 5/06/09 for petition filed on November 18, 2008, 
requesting to set aside non final office action mailed September 18, 2008, and to 
reinstate the Appeal Brief that was pending at the time the pending non final office 
action was mailed, is acknowledged. However, Applicant filing of amendment filed 
05/04/09 in response to office action mailed 02/05/09 renders this decision dismissed 
as moot . 

3. Claims 1-8, 19, 21-25, and 27-30 rejected under 35 U.S.C. § 101 is obviated by 
amendment to the claims filed 5/04/09, thus this rejection is hereby withdrawn. 

4. Applicant's arguments presented filed 5/04/09 regarding the objection to claim 1 1 
are persuasive, thus objection is hereby withdrawn. 
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Response to Arguments 

A. Regarding the rejection of claims 1-4, 6-9, 11-14, 16-25, 27 and 30 under 35 
U.S.C. §1 02(e) over Turek it is argued that Turek neither expressly nor inherently 
discloses each and every element of the invention defined by the claim. 

Specifically, with respect to claim 1 as amended, it is argued that Turek does not 
disclose a network management module that causes the processor to launch migratory 
recovery modules into the network to monitor status of each of the network nodes, as 
now recited. 

Because according to applicant's interpretation: 

(i) the mobile software agents are deployed by the dispatch mechanism (15) in 
the management server (14) only in response to either a report of a "network fault", 
alarm or other such trigger" (col. 7, lines 3-4) or a "request for maintenance in some 
non-specified area of the network" (col. 7, line 7) and the dispatched agents cease 
migrating after reaching their respective target nodes. Applicant further adds that 
diagnosing and correcting network problems does not constitute monitoring the status of 
each of nodes in a network. 

(ii) The dispatch mechanism 15 deploys a selected one of the software agents to 
the particular location of a fault or a particular area of a network where the fault is likely 
to have occurred (see, e.g., col. 7, lines 1-57). If the initial given node location does not 
contain the specific fault for which the software agent was deployed, the software agent 
identifies "a subset of nodes (associated with the given node) that remain candidates for 
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locating the error" (col. 8, lines 31-32). Once the particular fault is located and 
diagnosed, the software agent attempts to fix the problem (see col. 9, lines 21-22). 

(iii) Turek does not teach or suggest anything that that would have led one skilled 
in the art at the time the invention was made to believe that the software agent migrates 
to any other nodes after attempting to "effect repairs" and reporting back with the 
diagnosis. To the contrary, in accordance with Turek' s teachings, each of the mobile 
software agents is deployed to diagnose and, if possible correct, only one particular 
network fault (see, e.g., col. 5, lines 43-60) 

Therefore, there is no apparent need for any of Turek's software agents to migrate from 
the node that contains the particular network fault that the software agent was deployed 
to diagnose and correct. 

(iv) One skilled in the art at the time the invention was made would not have had any 
basis for believing that Turek' s system launches migratory recovery modules into a 
network to monitor status of each of the network nodes, as recited in claim 1. In 
accordance with its ordinary and accustomed meaning, the verb "monitor' means "to 
watch, keep track of, or check usually for a special purpose" (Merriam-Webster's 
Collegiate Dictionary, Tenth Edition (1995). 

(v) The software agents in Turek's are designed to recursively narrow the search 
for the particular network nodes for which they were respectively deployed and, after 
arriving at the target network nodes, the software agents attempt to effect repairs and 
report back diagnoses; the dispatched agents cease migrating after reaching their 
respective target nodes. That is, the software agents are not configured to determine 
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the status of each of the network nodes, as recited in claim 1 . Moreover, Turek only 
teaches that each of the software agents is configured to determine whether a particular 
event originated from a node (see col. 2, lines 49-53). Turek does not teach that these 
agents are configured to determine the status of their respective target nodes. 
Consequently, the dispatch mechanism (15) is not configured to provide periodic 
monitoring of the status of each of the network nodes, as recited in claim 1 . 

In response to the above mentioned argument, applicant's interpretation of the applied 
reference has been fully considered. 

Regarding point (i) the deployment only in response to either a report or a 
request for maintenance and to cease migrating after reaching their respective target 
nodes are features not commensurate with the scope of the claim, because the claim 
limitation does not recite ...to launch migratory recovery modules into the network to 
monitor status of each of the network nodes not in response to a report or request nor 
migrating after reaching a respective target node.. 

Regarding point (ii) in accordance with applicant's definition of the claimed term 
"monitor", which means to watch, keep track of, or check usually for a special purpose. 
It is noted that in view of this definition, the test to determine whether a fault originated 
at a given node is "monitoring" as defined by applicant. Turek disclosed that "migration 
is effected by targeting the software agent to a given node and then having the agents 
find its way to the actual fault through a recursive migration process,... when the agent 
arrives at a given node, as step (68) a test is performed to determine whether a fault 



Application/Control Number: 09/895,235 Page 6 

Art Unit: 2443 

originated from the given node (column 8, lines 20-32). Thus, effectively, Turek teaches 
launching migratory recovery modules (software agent) into the network to monitor (e.g. 
check usually for a special purposes) status (e.g. failure) of each of the network nodes. 

Regarding point (iii) that Turek's software agent would not migrates to any other 
nodes after attempting to "effect repairs" and reporting back with the diagnosis and 
where in accordance with Turek's teachings, each of the mobile software agents is 
deployed to diagnose and, if possible correct, only one particular network fault. 
Therefore, there is no apparent need for any of Turek's software agents to migrate from 
the node that contains the particular network fault that the software agent was deployed 
to diagnose and correct. It is noted that migrating to any other node after attempting to 
effect repairs. ..is not commensurate with the scope of claim 1. Turek does not teach 
deploying an agent to diagnose and if possible correct only one particular network fault. 
One objective of the Turek's patent is to collect information about conditions as mobile 
software agents are dispatched and migrated throughout a large computer network to 
correct network faults, wherein such information is then useful in diagnosing new faults 
(column 2, lines 22-26, see cycle routine of Fig. 6). Thus, applicant's interpretation that 
the agent correct only one particular network fault is inconsistent with the reference's 
disclosure. 

Regarding point (iv) contrary to applicant's interpretation of Turek that one would 
not have had any basis for believing that Turek' s system launches migratory recovery 
modules into a network to monitor status of each of the network node, Turek discloses 
that as the software agent is migrating toward a subset of nodes information collected 
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by the software agent is returned to the dispatch mechanism and stored in the database 
for future use (column 8, lines 44-47).The system management framework supports 
network usage monitoring, printer or other configuration management, and the like 
(column 4, lines 22-29). Thus, in view of the teachings of Turek, applicant's 
interpretation is not persuasive. 

Regarding point (v) wherein the software agents of Turek are configured to 
determine whether a particular event originated from a node, thus not configured to 
determine the status of their respective target nodes. According to the invention's 
disclosure, the status of the node includes information relating to any failed node 
process [par 030]. Thus, given the broadest reasonable interpretation inlight of the 
specification, determining the status of a node does not exclude determining whether 
there is a failure on the node. Turek teach where the software agent arrives at a given 
node, and performs a test to the determining whether a fault occurred on the given node 
(column 8, lines 21-27), thereby determining the status of the node. 

B. Turek also does not disclose a network management module that "monitors 
transmissions that are received from the recovery modules to provide periodic 
monitoring of the status of each of the network nodes", as claimed 

According to applicant's interpretation of the reference cited portion col. 7, lines 
58-67 - col. 8, lines 1-9, Turek does not provide any details about which component 
performs the test that is "done" at step 50 of Fig. 4, nor does Turek reveal anything 
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about the type of information that is input into the test nor the nature of the outcome of 
the test that indicates whether or not the software agent has arranged at the fault 
location. Without such details there is no basis on which one skilled in the art 
reasonably could conclude that Turek's dispatch mechanism monitors transmissions 
that are received from the software agent to provide periodic monitoring of the status of 
the network nodes. For example, one reasonably could imagine an embodiment in 
which the software agent transmits to the display agent a message that indicates 
whether or not the software agent has arrived at the targeted fault location. Such a 
message reveals the status of the software agent, not the node. 

In response to the above mentioned argument applicant's interpretation of the 
cited portion has been considered. However, Turek's discussion of the problem to 
solve is directed to management framework that manages computer resources on a 
large geographically dispersed network environment manages large local storages and 
spawn may simultaneous process to handle request from users, including maintenance 
problems the odds of a machine failure or other fault. According to Turek the 
problem of keeping a distributed management framework connected is a continuous 
job. Any number of everyday actions can server a connection or otherwise contribute to 
a fault condition (column 1, lines 11-48). Turek discloses a method of diagnosing a 
fault in such an environment by deploying a management infrastructure throughout the 
computer network... the selected software agent is then deployed into the computer 
network to diagnosis the fault. If the location of the fault is indeterminate, the software 
agent migrates to the location by gathering information about the fault as it traverses 
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the network (abstract). The test performed is to determine whether an "event", e.g. 
fault has occurred (column 7, lines 2-6, 17-18). 

Applicant's arguments that Turek does not reveal anything about the type of 
information that is input into the test nor the nature of the outcome of the test that 
indicates whether or not the software agent has arranged at the fault location, are not 
persuasive. 

Applicant further argues that Turek does not teach "the network management 
module monitors transmissions that are received from the recovery modules to provide 
periodic monitoring of the status of each of the network nodes", as claimed because the 
dispatched agents cease migrating after reaching their respective target nodes. Thus, a 
particular node can be expected to be visited only once by the software agent that is 
deployed by the dispatch mechanism. Accordingly, such a deployment of software 
agents could not possibly provide periodic monitoring of the status of each of the 
network nodes. 

In response to the above mentioned argument, applicant interpretation of Turek 
is noted. 

However, Turek's objective is to automate the diagnosis of network events in a large, 
distributed computer network (column 2, lines 8-11). Particularly, given the maintenance 
problems discussed by Turek in existing distributed network system and the odds of a 
machine failure or other fault, where keeping a distributed management framework 
connect is a continuous job and any number of everyday actions can server a 
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connection or otherwise contribute to a fault condition (column 1, lines 11-48) and the 

event history information (column 7, lines 30-48). 

One skilled in the art could reasonably conclude that Turek's dispatch 
mechanism monitors transmissions that are received from the software agent to 
provide periodic monitoring of the status of the network nodes. For example, one 
reasonably could imagine an embodiment in which the software agent transmits 
information about the performed test to determine whether a "event", e.g. fault has 
occurred, such a message revealing the status of the node continuously on a daily 
bases or at shorter intervals of time dynamically based on the gathered information 
about the fault as it traverses the network, and thus provide a clue regarding how new 
events should be addressed. Arguments stating that because the software agents 
cease migrating after reaching their respective target nodes, one can expect a node to 
be visited only once by the software agents and that such a deployment of software 
agents could not possibly provide periodic monitoring of the status of each of the 
network nodes are not persuasive. 

C. Regarding claims 2-4, 6-9, 21-25, and 30, each of these incorporates the 
features of independent claim 1 and therefore are not patentable over Turek for at least 
the same reasons explained above. 
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D. Regarding claim 11, it is argued that Turek's software agents do not perform any 
of elements (c) after initiating the recovery process, migrating from the current network 
node to a successive one of the network nodes; and (d) repeating (a), (b), and (c) with 
the current network node corresponding to the successive network node for each of the 
nodes in the network, as recited on claim 1 1 . 

In accordance with Turek's teachings, the mobile software agents do not migrate 
from a current network node to a successive one of the network nodes after initiating a 
recovery process on the current network node. Because, after initiating a recovery 
process, Turek's mobile software agents merely report the problem and the corrective 
action that was taken to the dispatch mechanism 15 (see col. 8, lines 6-9; FIG. 4). 
Therefore, there is no apparent need for any of Turek' s software agents to migrate from 
the node that contains the particular network fault that the software agent was deployed 
to diagnose and correct. Thus, Turek does not disclose either element (c) or element (d) 
of claim 11. 

In response to the above mentioned argument Turek clearly discloses that software 
agents migrate throughout the network {I.E from one network node to another} to 
diagnose and correct the network faults (col. 5, lines 32-60). 

E. Regarding claims 12-14 and 16-19, each incorporates the features of 
independent claim 1 1 and therefore is not patentable over Turek for at least the same 
reasons explained above. 
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F. Regarding claim 20, as amended, claim 20 is unpatentable over Turek in 
view of Sreenivasan for at least the same reasons explained above in connection with 
independent claim 11. 

G. Rejection of claims 5 and 15 under 35 U.S.C. § 1030) over Turek in view of 
Sreenivasan. Claim 5 recites that "the recovery module causes the second network 
node to determine a status of the second network node in accordance with a heartbeat 
messaging protocol." 

Applicant argues that applied reference does not teach this claim limitation as 
recited, because, given the limited information provided by heartbeat messages, they 
cannot be used to "diagnose and, if possible, correct a network fault" as required of the 
mobile software agents (see Turek, col. 5, lines 41-42). Instead, the mobile software 
agents perform these tasks by performing tests at the nodes to which the software 
agents were deployed by the management server 14 (see col. 7, line 58 - col. 8, line 9). 
Thus, Turek fails to disclose or suggest software agents that determine the "status" of a 
network node, where the "status" is determinable in accordance with a heartbeat 
messaging protocol. 

Sreenivasan according to applicant does not disclose anything about recovery 
modules of the type disclosed in Turek, much less anything about such modules that 
"cause the second network node to determine a status of the second network node in 
accordance with a heartbeat messaging protocol." Because (i) "software running on 
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each sewer 12 use private network 18 to exchange heartbeat and other control 
messages." (ii) the CMD processes running on the servers of the Sreenivasan's cluster 
constitute "recovery modules." because they are not mobile and do not determine a 
status of itself in accordance with a heartbeat messaging protocol; instead, the CMD 
processes transmit heartbeat messages between different nodes. 

In response to the above mentioned argument that the recovery module in Srinivasan is 
not mobile and do not determine a status of itself is irrelevant because the claim 
limitation is directed towards a software agent determining the status of the node rather 
than the status of itself . Examiner notes and has also indicated in the rejection that 
Sreenivasan was introduced because its "software agent" showed the "heartbeat 
messaging protocol" functionality while Turek did not explicitly disclose that its "software 
agent" has that functionality. Sreenivasan also discloses a software agent (Daemon) 
that is present on the network nodes and provides the status information "I'm alive 
message" from nodes (paragraphs. 78, 111 & 112). Therefore that it is proper to 
combine Turek and Sreenivasan to anticipate applicant's claimed invention. 



H. Applicant argues that the rationale given in support of the combination of 
Turek and Sreenivasan does not establish a prima facie case of obviousness. 
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The rationale given by the Examiner in support of his proposed combination of 
Turek and Sreenivasan does not establish a prima facie case of obviousness because 
the incorporation of a heartbeat messaging protocol into the management server 14 to 
determine the status of a network node as disclosed by Sreenivasan (i.e., by 
exchanging heartbeat messages between software running on each server) would not 
result in the invention defined in claim 5, where "the recovery module is configured to 
determine the status of a network node in accordance with a heartbeat messaging 
protocol." 

In response to the above mentioned argument examiner notes and also indicated 
in the rejection that Sreenivasan was introduced because its "software agent" showed 
the "heartbeat messaging protocol" functionality while Turek did not explicitly disclose 
that its "software agent" has that functionality. Sreenivasan also discloses a software 
agent (Daemon) that is present on the network nodes and provides the status 
information "I'm alive message" from nodes (paragraphs. 78, 111 & 1 12). 

I. Applicant argues one skilled in the art at the time the invention was made 
would not have had any apparent reason to modify the teachings of Turek in 
the manner proposed by the Examiner. 

In accordance with Turek's teachings, the software agents are deployed only 
after an event, such as a network fault, has been determined by the management 
server 14. Therefore, there is no need for the software agents to use a heartbeat 
messaging protocol to determine whether such an event originated from a particular 
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node. Instead, each software agent need only be tailored to specifically identify the 
particular network fault that triggered the deployment of the software agent by the 
management server 14. As explained above, such information is not determinable in 
accordance with a heartbeat protocol due to the limited nature of the information 
conveyed by the heartbeat messages (i.e., "I'm here, are you here?"). 

For at least this reason, one skilled in the art at the time the invention was made 
would not have had any apparent reason to modify the teachings of Turek in the 
manner proposed by the Examiner. 

In addition, even assuming only for the purposes of argument that Turek's 
migratory agents could be modified to run the CMD processes, one skilled in the art 
would not have had a reasonable basis for believing that the CMD framework would 
work when running on migratory software agents of the type described in Turek. In 
particular, the CMD framework is designed to operate with each of the CMDs running 
on a single respective server of a cluster. 

In response to the above mentioned argument examiner notes that Turek does 
disclose software agents that monitor network conditions (col. 2, lines 22-26) and report 
errors (col. 5, lines 32-35) however Turek did not explicitly disclose that network node 
status information being conveyed utilizes "heartbeat messaging protocol". Therefore 
prior art Sreenivasan was introduced which also disclosed a software agent resident on 
the node that provided the status of the node via "heartbeat messaging protocol". 
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J. Claim 15 depends from independent claim 1 1 and recites that "the status of a 
network node is determined in accordance with a heartbeat messaging protocol." 

Sreenivasan does not make-up for the failure of Turek to disclose or suggest the 
elements of independent claim 1 1 discussed above. Indeed, Sreenivasan does not 
disclose anything about recovery modules of the type disclosed in Turek, much less 
anything about such modules that are "configured to determine the status of a network 
node in accordance with a heartbeat messaging protocol." Moreover, one skilled in the 
art at the time the invention was made would not have had any apparent reason to 
combine Turek and Sreenivasan in the manner proposed by the Examiner for the 
reasons explained above in connection with independent claim 5. 

In response to the above mentioned argument Examiner notes that this rejection is 
based on a combination two prior arts rejected under 35 U.S.C 103 and has cited 
pertinent excerpts from Turek to address this functionality. Examiner notes and has also 
indicated in the rejection that Sreenivasan was introduced because its "software agent" 
showed the "heartbeat messaging protocol" functionality while Turek did not explicitly 
disclose that its "software agent" has that functionality. Sreenivasan also discloses a 
software agent (Daemon) that is present on the network nodes and provides the status 
information "I'm alive message" from nodes (paragraphs. 78, 111 & 1 12). Therefore that 
it is proper to combine Turek and Sreenivasan to anticipate applicant's claimed 
invention. 
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L. Regarding claim 28, claim recites that the network management module causes 
the processor to statistically identify target ones of the network nodes that are needed to 
achieve a specified confidence level of network monitoring reliability, and the network 
management module causes the processor to launch the recovery modules into the 
network by transmitting respective ones of the recovery modules to the identified target 
network nodes. 

In cited disclosure, Douik merely compares observed events to stored 
performance data and statistics in order to determine a suspected fault to explain the 
observed events and symptoms. Douik does not even hint that target nodes are 
identified statistically to achieve a specified confidence level of network monitoring 
reliability. Moreover, Douik does not teach or suggest anything about migratory recovery 
modules and launching the recovery modules into the network by transmitting 
respective ones of the recovery modules to the identified target network nodes. 

Examiner has objected to claim 28 and indicated it to be allowable subject matter once 
it is incorporated into the independent claims. 

M. Regarding claim 29, claim recites: determining a number of the recovery modules 
needed to achieve a specified network monitoring service level; statistically identifying 
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target ones of the network nodes to achieve a specified confidence level of network 
monitoring reliability, and transmitting the determined number of the recovery modules 
to the identified target network nodes. 

Claim 29 recites features that essentially track the pertinent features of claim 28 
discussed above. Therefore, claim 29 is patentable over Turek in view of Douik for at 
least the same reasons explained above in connection with claim 28. 

Examiner has objected to claim 28 and indicated it to be allowable subject matter once 
it is incorporated into the independent claims. 

Specification 

5. The disclosure is objected to because of the following informalities: The 
disclosure fails to disclose the term "computer-readable medium " as being claimed. 

Appropriate correction is required. 

Claim Rejections - 35 USC §112 

6. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

7. Claim 1 rejected under 35 U.S.C. 112, first paragraph, as failing to comply with 
the enablement requirement. The claim(s) contains subject matter which was not 
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described in the specification in such a way as to enable one skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and/or use the invention. 
Lines 8-14 of claim 1 states "wherein each of the recovery modules is configured to: 

cause any given one of the network nodes to migrate the network node from the given 
network node to another one of the network nodes; cause any given one of the network 
nodes to determine a respective status of the given network node; and cause any given 
one of the network nodes to initiate a recovery process on the given network node in 
response to a determination that the given network node has one or more failed node 
processes". This limitation is talking about migrating a node to another node which is 
not consistent with applicant's disclosure. Appropriate correction is required. 

8. Claims 2-4, 6-9, 21-25, 27 & 28 are also rejected under 35 U.S.C. 112, first 
paragraph by virtue of their dependence on clam 1 . 

9. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

10. Claim 1 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. 

1 1 . Lines 8-1 4 of claim 1 states "wherein each of the recovery modules is configured 

to: cause any given one of the network nodes to migrate the network node from the 
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given network node to another one of the network nodes; cause any given one of the 
network nodes to determine a respective status of the given network node; and cause 
any given one of the network nodes to initiate a recovery process on the given network 
node in response to a determination that the given network node has one or more failed 
node processes". This limitation is talking about migrating a node to another node which 
is indefinite language and is also not consistent with the disclosure. Appropriate 
correction is required. 

12. Claim 1 recites on lines 4-7 of claim which states " a processor coupled to the 
memory, operable to execute the instructions, and based at least in part on the 
execution of the instructions operable to perform operations comprising executing a 
network management module that causes the processor to launch migratory recovery 
modules into the network to monitor status of each of the network nodes" then again 
lines 15-16 states " wherein in the executing the network management module causes 
the processor to launch the recovery modules in order to determine the status of each 
of the network nodes". There is insufficient antecedent basis for this limitation in the 
claim hence making the claim language indefinite. Appropriate correction is required. 

13. Claim 19 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. Lines 3-4 of the claim states "wherein each of the recovery 
modules is configured to migrate from one recipient one of the network nodes to 
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another ." The claim language is indefinite and needs to be amended to correctly convey 
the indented limitation. 

14. Claim 22 recites the limitation "The computer readable medium of claim 21" in 
line 1 . However neither upward successive claims 21 nor claim 1 mention any 
"computer readable medium". There is insufficient antecedent basis for this limitation in 
the claim. 

15. Claims 2-4, 6-9, 21-25, 27 & 28 are also rejected under 35 U.S.C. 112, second 
paragraph by virtue of their dependence on clam 1 . 



Claim Rejections - 35 USC § 102 

16. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351 (a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

17. Claims 1-4, 6-9, 11-14, 16-25, 27 & 30 are rejected under 35 U.S.C. 102(e) as 



being anticipated by Turek et al (U.S.6,460,070). 



Application/Control Number: 09/895,235 Page 22 

Art Unit: 2443 

18. As per claims 1 Turek disclosed a method for managing a plurality of distributed 
nodes of a network (Abstract), comprising: a memory storing computer readable 
instructions (col. 10, lines 29-43): and a processor coupled to the memory, operable to 
execute the instructions, and based at least in part on the execution of the instructions 
operable to perform operations (col. 9, lines 66-67 & col. 10, lines 1-2) comprising 
executing a network management module {dispatch mechanism} that causes the 
processor to launch migratory recovery modules into the network to monitor status of 
each of the network nodes (col. 2, lines col. 8, lines 18-33); wherein each of the recovery 
modules is configured to: cause any given one of the network nodes to migrate the 
network node from the given network node to another one of the network nodes 
(col .8, lines 18-33); cause any given one of the network nodes to determine a respective 
status of the given network node; and cause any given one of the network nodes to 
initiate a recovery process on the given network node in response to a determination 
that the given network node has one or more failed node processes (col. 8, lines 18-33 & 
col.4, lines 42-49); wherein in the executing the network management module causes 
the processor to launch the recovery modules in order to determine the status of each 
of the network nodes (col .8, lines 19-33); and wherein in the executing the network 
management module causes the processor to monitor transmissions that are received 
from the recovery modules executing on respective ones of the network nodes in order 
to provide periodic monitoring of the status of the network nodes (col. 2, lines 22-26 & 
col.8, lines 39-52). 
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1 9. As per claims 11, 1 9 & 20 Turek disclosed a method for managing a plurality of 
distributed nodes of a network, comprising: (a) on a current one of the network nodes, 
determining a status of the current network node (col. 2, lines col. 8, lines 18-33); (b) in 
response to a determination that the current network node has one or more failed node 
processes, initiating a recovery process on the current network node (col. 7, lines 58-67 
& col. 8, lines 1-9); (c) after initiating the recovery process, migrating from the current 
network node to a successive one of the network nodes (col. 5, lines 32-60, col. 7, lines 
58-67 & col.8, lines 19-33); and repeating (a) ,(b), and (c) (col.2, lines 61-62) with the 
current network node corresponding to the successive network node for each of the 
nodes in the network {addressed in prior art excepts of a, b, & c above}. 

20. As per claims 2, 12,21, 23, 24 & 25 Turek disclosed the system of claim 1 , 
wherein at least one of the recovery module comprises a respective routing component 
this is executable by a given one of the network nodes (Turek, col. 5, lines 32-60) to 
cause the given network node determine next hop addresses for migrating the recovery 
module from the given to a successive destination network nodes col. 7, lines 58-67 & 
col.8, lines 19-33). 

21 . As per claims 3 & 1 3 Turek disclosed the system of claim 2, wherein the routing 
component is executable by the given network node to cause the given network node 
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to determine the next hop address based upon a routing table stored at the origin 
network node (Turek, col. 5, lines 32-60) 

22. As per claims 4 & 14 Turek disclosed the system of claim 1 , wherein at least one 
of the recovery module is executable by the given network node to cause the given 
network node to determine the status of the given network node by sending an inter- 
process communication to a node process executing on the given network node (Turek, 
col.3, lines 65-67, col.4, lines 1-12 & col.5, lines 32-60). 

23. As per claims 6 & 1 6 Turek disclosed the system of claim 1 , wherein each of the 
recovery module is executable by the given network node to cause the given network 
node to perform operations comprising: determining whether the given network node 
has one or more failed processes, initiating a recovery process on the given network 
node in accordance with a restart protocol (Turek, col. 6, lines 23-59). 

24. As per claims 7 & 1 7 Turek disclosed the system of claim 6, wherein each of the 
recovery module is executable by the given network node to cause the given network 
node to respond to a determination that the given network node has a failed process by 
initiating a restart of the failed process by transmitting a request to a process execution 
service operating on the given network node (Turek, col. 6, lines 23-59). 
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25. As per claims 8 & 1 8 Turek disclosed the system of claim 1 , wherein each of the 
recovery module is executable by the given network node to cause the given network 
node to transmit a respective node status message to the network management module 
(Turek, col.2, lines 22-62). 

26. As per claim 9 Turek disclosed the system of claim 8, wherein each of the node 
status messages comprises information obtained from a respective log file generated at 
a respective failed one of the network node (Turek, col.8, lines 58-67 & col. 8, lines 1-9). 

27. As per claim 22 Turek disclosed the computer-readable medium of claim 21 , 
wherein the operating environment on each of the network nodes provides each of the 
recovery modules with access to status monitoring resources, recovery resources, and 
native operative system resources that are available at each of the network nodes 
(Turek, col.8, lines 39-52). 

28. As per claim 27 Turek disclosed the system of claim 1 , wherein the network 
management module causes the processor to determine a number of the recovery 
module needed to achieve a specified network monitoring service level, and to launch 
the determined number of recovery modules into the network to achieve the specified 
network monitoring service level (col.2, lines 36-46). 
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29. As per claim 30 Turek disclosed the system of claim 1 , wherein, in the execution, 
the network management module causes the processor to monitor number of network 
node failures reported by the recovery modules and causes the processor to launch 
more of the migratory modules into the network as the number of reported failures 
increases (Turek, col. 5, lines 32-67). 



Claim Rejections - 35 USC § 103 

30. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

31 . Claims 5, 1 5 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over 
Turek (U.S. 6,460,070) and Sreenivasan (U.S. Pub No. 2002/0049845 A1). 

32. As per claims 5 Turek disclosed a system for managing a plurality of distributed 
nodes of a network, comprising: first and second ones of the network nodes; wherein 
the first network node is operable to execute a recovery modules that causes the first 
network node to migrate the recovery module from the first network node to the second 
network node (col .5, lines 32-42 & col. 8, lines 18-33), and in response to receipt of the 
recovery module from the first network node, the recovery module causes the second 
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network node to determine a status of the second network node (col. 7, lines 58-67 & 
col. 8, lines 1-9) in accordance with a heartbeat messaging protocol, and in response to 
a response to a determination that the second network node has one or more failed 
processes, the recovery module causes the second network node to initiate a recovery 
process on the second network node (col.1, lines 65-67 & col. 2, lines 1-46). Although 
Turek disclosed software agent (module) providing network status information to the 
management module. However Turek did not specifically mentioned agent using a 
"heartbeat messaging protocol" to determine the status of a network node. In the same 
field of endeavor Sreenivasan disclosed daemon (module or software agent) sending "I 
am alive message" (heartbeat messaging protocol) to determine the status of a network 
node (paragraphs.78, 111 & 1 1 2). 

It would have been obvious to one in the ordinary skill in the art at the time the invention 
was made to have incorporated the functionality of daemon (module or software agent) 
sending "I am alive message" (heartbeat messaging protocol) to determine the status of 
a network node as disclosed by Sreenivasan in the a system for managing a plurality of 
distributed nodes of a network as disclosed by Turek in order to make the managing 
system more reliable and responsive resulting in determining accurate diagnosis and 
status of the network nodes. 

33. As per claim 1 5 Turek disclosed the method of claim 1 1 . Although Turek 
disclosed agents (modules) providing status information about the network nodes. 
However Turek did not explicitly disclose wherein the status of the network node is 
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determined in accordance with a heartbeat messaging protocol. In the same field of 
endeavor Sreenivasan disclosed daemon (module or software agent) sending "I am 
alive message" (heartbeat messaging protocol) to determine the status of a network 
node (paragraphs.78, 111 & 112). 

It would have been obvious to one in the ordinary skill in the art at the time the invention 
was made to have incorporated the functionality of daemon (module or software agent) 
sending "I am alive message" (heartbeat messaging protocol) to determine the status of 
a network node as disclosed by Sreenivasan in the a system for managing a plurality of 
distributed nodes of a network as disclosed by Turek in order to make the managing 
system more reliable and responsive resulting in determining accurate diagnosis and 
status of the network nodes. 



Allowable Subject Matter 

34. Claims 28 & 29 objected to as being dependent upon a rejected base claim, but 
would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 



35. Claim 28 is objected to as allowable subject matter which states "The system of 
claim 1, wherein the network management module causes the processor to statistically 
identify target ones of the network nodes that are needed to achieve a specified 
confidence level of network monitoring reliability, and the network management module 
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causes the processor to launch the recovery modules into the network by transmitting 
respective ones of the recovery modules to the identified target network nodes." 



36. Claim 29 is objected to as allowable subject matter which states "The method of 
claim 1 1 , further comprising on a respective one of the network nodes: determining a 
number of the recovery modules needed to achieve a specified network monitoring 
service level; statistically identifying target ones of the network nodes to achieve a 
specified confidence level of network monitoring reliability; and transmitting the 
determined number of the recovery modules to the identified target network nodes." 

Conclusion 

37. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to ASGHAR BILGRAMI whose telephone number is 
(571)272-3907. The examiner can normally be reached on 9-5. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tonia L.M. Dollinger can be reached on 571-272-4170. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 
273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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Examiner, Art Unit 2443 
/Tonia LM Dollinger/ 

Supervisory Patent Examiner, Art Unit 2443 



